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DEC 1 3 2008 

REMARKS 

Applicant acknowledges, with appreciation, the allowance of claims 1-6, and the 
indication that claims 1 1-19, 21-26 and 29^3 contain allowable subject matter. Claims 1^3 are 
currently pending, with claims 1, 7 and 20 being the independent claims. Claims 1-43 have been 
amended. No new matter has been added. Reconsideration of the application, as amended, is 
respectfully requested. 

a aims 11 and 12 were objected to based on certain informalities. In response to this 
objection, Applicant has amended the claims in a manner that is believed to address each specific 
objection. Withdrawal of the objections is requested. 

In the Office Action dated November 15, 2005, independent claims 7 and 20, and 
dependent claims 8-10 were rejected under 35 U.S.C §l03(a) as unpatentable over 3 rd Generation 
Partnership Project; Technical Specification Group Services and Systems Aspects QoS Concept 
(3G TR 23.907 version 1.1.0) ("TR 23.907"), while dependent claims 27 and 28 were rejected 
under 35 U.S.C. § 103(a) as unpatentable over TR 23.907 in view of Applicant's background of 
the present invention ("ABP7"). For the following reasons, it is respectfully submitted that all 
claims of the present application are patentable over the cited reference. 

Independent claim 7 has been amended to recite the steps of "detecting at least a delivery 
onler attribute (DO A) as a parameter set for a transmission pr otocol type used for transrifission 
of data packets " and "deciding whether said delivery order attribute parameter is set for said 
protocol type . Support for these amendments may be found, for example, in Fig. 3 A, step 
S31 and S32 and at pg. 15, lines 15-26 of the originally filed specification. No new matter has 

been added. 

The Office Action (pg. 3) stares: 
[TR 23,907] 

Detecting at least a delivery order attribute (Delivery order) 
as a parameter for transmission of data packets (a Delivery order 
which is part of the UMTS bearer service attributes is derived from 
the user protocol, PDP type, and detected, e.g. by the UMTS BS 
manager in the MT, CN EDGE, and the Gateway, page 13, lines 
9-17 of section 6.2.2.1, and page 17, lines 21 of section 6.4.2.1 - 
page 18, lines 1-4), 

Deciding whether said delivery order attribute parameter is 
set (3GPP also teaches that the Delivery order is set to "y" for 
out-of-sequence is not acceptable or "n'* for out-of-sequence is 
acceptable, page 17, lines 21 of section 6.4.2.1-page 18, lines l^t, 
therefore, the step of deciding whether the Delivery order is et to 
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"y" or "n" must be included after the Delivery order is derived 
from the PDP type). 

TR 23.907 fails to teach or suggest the method recited in amended independent claim 7, 
as well as the network element of correspondingly amended claim 20 in which the method of 
claim 7 is implemented. The delivery order attribute is described in the background of 
Applicant's originally filed specification, for example, at pg. 4, lines 15-27. As Stated therein, 
the delivery order attribute, i.e., a PDP context QoS parameter, is defined and included in a set of 
UMTS bearer QoS parameters. In addition, the specification states, the delivery order attribute 
parameter (DOA>defines whether the order of transmitted packages must be maintained for the 
UMTS. 

TR 23.907 (pg. 13, paragraph 6.2.2.1) teaches that the UMTS BS manager in the MT, CN 
EDGE and the Gateway signal between each other and via the translation function with external 
instances to establish or modify a UMTS bearer service. TR 23.907 (pg. 13, paragraph 6.2-2.1) 
further teaches that each of the UMTS BS managers interrogates its associated 
admission/capability control to determine whether the network entity supports the specific 
requested service and whether the required resources are available. Furthermore, TR 23.907 (pg. 
13, paragraph 6.2.2.1) teaches that the CN EDGE UMTS BS manager verifies with the 
subscription control the administrative rights for using the service^ However, TR 23.907 failsto 
teach or suggest "detecting at least a delivery order attribute (DOA) as a parameter set for a 
transmission protocol type used for transmission of d ata packets" as recited in amended 
independent claim 7, or as defined in correspondingly amended independent claim 20. 

TR 23.907 (pg. 17, paragraph 6.4.2.1) teaches that the delivery order attribute indicates 
whether or not a UMTS bearer shall provide m-sequence SDU delivery. TR 23.907 (pg. 17) 
states, "the [delivery order attribute] is derived from the user protocol [PDP type] and specifies 
[whether] out-of-sequence SDUs are acceptable". TR 23.907 (pg. 17, paragraph 6.4.2.1) does not 
teach "deciding whether said delivery order attribute parameter is set for said protocol type," as 
recited in amended independent claim 7, or as defined in correspondingly amended independent 
claim 20. 

TR 23 907 (pg. 18, lines 3-4) also states, "the attribute is derived from the user protocol 
[PDP type] and specifies if out of sequence SDU's are acceptable or not" and that "This 
information cannot he extracted from the traffic class". TR 23.907 fails to teach or suggest 
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that the delivery attribute is set for the PDP type. Rather, TR 23.907 clearly teaches that the 
delivery order attribute is set for the traffic class. 

Such a concept is derivable from TR 23.907 (pg. 20, paragraph 6.4.2.3), which discloses 
a table summarizing the UMTS bearer attributes. TR 23.907 (pg. 20, paragraph 6.4.2.3) states, 
"in Table 2, the defined UMTS bearer attributes and their relevancy for each bearer class are 
summarized". Again, TR 23.907 (pg. 17) states, "this information [i.e., the delivery order 
attribute] cannot be extracted from the traffic class". TR 23.907 (Table 2) thus perm^he skilled 
person to derive that a UMTS bearer as a PDP context specifies the traffic class and'the delivery 
order attribute for the respective traffic class . However, TR 23.907 teaches that the deliver y, 
order attribute is only associated with a respec tive traffic class. Put differently, TR 23.907 
teaches what is described in the background section of the specification of the instant 
application, i.e., a delivery order attribute that defines whether the order of transmitted packages 
must be maintained for the UMTS. 

Allowed independent claim lis directed to the method set forth in the flow chart of Fig. 
2, which performs the steps associated with setting a delivery order attribute for a specific 
predetermined type of a PDP context such that the delivery order attribute becomes a new quality 
of service (QoS) parameter for a PDP context Independent claim 7 is a method associated with 
the setting of the new QoS parameter for a1*DP context, wherein clairn 7 and corresponding 
claim 20 define the respective data communication using such a PDP context. Specifically, 
independent claim 7 is directed to the method set forth in the flow chart of Fig. 3, where 
independent claim. 20 is the corresponding network element in which the method of claim 7 is 
implemented. Therefore, independent claims 7 and 20 are also allowable for the same reasons 
associated with claim 1. 

In accordance with the claimed invention, PDP context QoS parameters are detected and 
a check is performed to determine whether a delivery orde r attribute is set for the transmission 
protocol type, e.g.. the PDP context which is used for transmission. The traffic class is 
determined only after such a determination is made, where different types of processing are 
applied to different types of traffic classes. Consequently, the claimed invention is directed to 
performing data packet transmissions based on at least an evaluation of a delivery order 
parameter that is set for a specific transmission protocol type, i.e., PDP type. Here, the claimed 
invention advantageously uses a "known" parameter (i.e., the delivery order attribute) in a 
different hierarchical layer of the communication network protocol. 
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TR 23.907 fails to teach the use of the delivery order attribute in the claimed manner. TR 
23.907 teaches that the delivery attribute parameter only provides an indication of whether 
out-of-sequence SDUs are acceptable. TR 23.907 teaches that the delivery order attribute is only 
associated with a respective traffic class . Moreover, as noted previously, TR 23.907 specifically 
states that the delivery order information cannot be extracted fro m the traffic class. Thus, TR 
23.907 fails to teach or suggest "detecting at least a delivery order attribute (DOA) as a 
parameter set for a transmission protocol type used for frat^rni^on of data packets , . . and... 
deciding whether said delivery order attribute parameter is set for sai d protocol type" or the 
corresponding network element of amended claim 20 in which the method of claim 7 is 
implemented. Accordingly, independent claim 1 , and amended claims 7 and 20 are all patentable 
over TR 23.907 and therefore, withdrawal of all the rejections under 35 U.S.C. §103 is in order, and 
a notice to that effect is earnestly solicited. 

In view of the patentability of independent claim 1 , 7 and 20, for the reasons set forth above, 
dependent claims 2-6, 8-19 and 21-43 are all patentable over the prior art- 
Based on the foregoing amendments and remarks, this application is in condition for 
allowance. Early passage of this case to issue is respectfully requested. 

Respectfully submitted, 
COHEN PQNTANI LBBBERMAN & ] 




ipr 
Res^ 
SSrRlth Avenue, Suite 1210 
New York, New York 10176 
(212) 687-2770 



Dated: December 13, 2006 
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